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

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

On 16.11.2015 20:28, asetofsymbols@gmail.com wrote:
> 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...

OK.  So what you're saying is that whenever a function is
called, it is called using a number.  And yes, I see that
using objdump.

It also looks like numbers are used for library (external)
functions as well, as some sort of indirection can be seen
in the objdump:

08048324 <putc@plt>:
  8048324:       ff 25 a4 96 04 08       jmp    *0x80496a4
  804832a:       68 18 00 00 00          push   $0x18
  804832f:       e9 b0 ff ff ff          jmp    80482e4 <_init+0x30>
[...]
  8048430:       e8 ef fe ff ff          call   8048324 <putc@plt>
  8048435:       b8 00 00 00 00          mov    $0x0,%eax

-Morten

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

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

On 16/11/15 20:14, Morten W. Petersen wrote:
> 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?
> 

Names are not used in the generated object code (unless you use
"__func__" in gcc or some other way of adding function names to the
code).  Names will be included in linkable object files for linkage,
debugging information, etc., but they are not used in the final linked
machine code that is run.

So a function with longer names will give slightly bigger source files,
object files, elf files, etc., but it makes no difference at runtime.

(IIRC you are a Python programmer - in Python, the identifiers are used
directly for lookup when calling a function, and thus long names means
very marginally bigger and slower code.  But C is a fully compiled
language, and names are lost when the final code is generated.)

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

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

David Brown <david.brown@hesbynett.no> writes:
[...]
> Names are not used in the generated object code (unless you use
> "__func__" in gcc or some other way of adding function names to the
> code).  Names will be included in linkable object files for linkage,
> debugging information, etc., but they are not used in the final linked
> machine code that is run.

It depends.  Symbols that are visible to the linker may be included in
the executable file.  On Unix-like systems, run "nm" to see what symbols
are included.  These symbols may be stripped out, or not included in the
first place, depending on how you invoke the linker.  But (as I
understand it) they're not generally loaded into memory when you run the
program.  (Things may or may not be similar on non-Unix-like systems.)

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

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

Keith Thompson <kst-u@mib.org> wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Names are not used in the generated object code (unless you use
>> "__func__" in gcc or some other way of adding function names to the
>> code).  Names will be included in linkable object files for linkage,
>> debugging information, etc., but they are not used in the final linked
>> machine code that is run.
 
> It depends.  Symbols that are visible to the linker may be included in
> the executable file.  On Unix-like systems, run "nm" to see what symbols
> are included.  These symbols may be stripped out, or not included in the
> first place, depending on how you invoke the linker.  But (as I
> understand it) they're not generally loaded into memory when you run the
> program.  (Things may or may not be similar on non-Unix-like systems.)

The OS/360 (and successor) linkage editor can read its own output.

At the time OS/360 was being developed, compilers were slow.
They wanted the ability to recompile only procedures that changed,
and replace those in a previously linked program. That is where
the name linkage editor comes from.  There is a simple rule that
if two CSECTs with the same name appear, the first one is used.
Put all the new ones into the input INCLUDE (linkage editor
control card) the old load module, and write out the new one.

The ESD (external symbol dictionary) isn't all that big, and is
ignored when reading one in to execute. 

In addition, it is usual for OS/360 compilers (and assembly 
programmers) to put the name at the beginning of each ENTRY
(assembler instruction) point with a branch around it. 
Traceback routines and debuggers know where to find them, and
print them out. 

OS/360, and still with z/OS, uses a doubly linked list for
linkage instead of a stack, which sometimes makes it easier
to do tracebacks.

-- glen

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

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

On Tue, 17 Nov 2015 20:12:12 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Keith Thompson <kst-u@mib.org> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> Names are not used in the generated object code (unless you use
>>> "__func__" in gcc or some other way of adding function names to the
>>> code).  Names will be included in linkable object files for linkage,
>>> debugging information, etc., but they are not used in the final linked
>>> machine code that is run.
> 
>> It depends.  Symbols that are visible to the linker may be included in
>> the executable file.  On Unix-like systems, run "nm" to see what symbols
>> are included.  These symbols may be stripped out, or not included in the
>> first place, depending on how you invoke the linker.  But (as I
>> understand it) they're not generally loaded into memory when you run the
>> program.  (Things may or may not be similar on non-Unix-like systems.)
>
>The OS/360 (and successor) linkage editor can read its own output.
>
>At the time OS/360 was being developed, compilers were slow.
>They wanted the ability to recompile only procedures that changed,
>and replace those in a previously linked program. That is where
>the name linkage editor comes from.  There is a simple rule that
>if two CSECTs with the same name appear, the first one is used.
>Put all the new ones into the input INCLUDE (linkage editor
>control card) the old load module, and write out the new one.


One of the downsides to that was that the linkage editor was dog slow.
So you could save some time when you only wanted to replace a few
CSECTs, but you were penalized all the rest of the time when you were
doing an ordinary compile/link cycle.

Of course slow linkers still plague us.

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

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

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip on unix linker and saving external symbols)
(then I wrote)

>>The OS/360 (and successor) linkage editor can read its own output.

>>At the time OS/360 was being developed, compilers were slow.
>>They wanted the ability to recompile only procedures that changed,
>>and replace those in a previously linked program. That is where
>>the name linkage editor comes from.  There is a simple rule that
>>if two CSECTs with the same name appear, the first one is used.
>>Put all the new ones into the input INCLUDE (linkage editor
>>control card) the old load module, and write out the new one.
 
> One of the downsides to that was that the linkage editor was dog slow.
> So you could save some time when you only wanted to replace a few
> CSECTs, but you were penalized all the rest of the time when you were
> doing an ordinary compile/link cycle.

I don't know that it would have been faster any other way, though.

Subroutine libraries are load module (linker output) libraries,
which suggests that is is faster to read them, than object modules.

Compilers and assemblers normally only have to work on a small part
(one object module) at a time, but the linker has to do the whole thing,
and maybe in small memory. There are 44K, 88K, and 128K byte versions.

> Of course slow linkers still plague us.

And there was the loader when you didn't need to write a load module.

but I think that came a little later.

-- glen

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

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

On 16/11/15 18:51, asetofsymbols@gmail.com wrote:
> I have a different experience;
> The code more readable:

Nobody is stopping you from reading the code. Feel free.

If you want other people to read the code, though, you'll have to make 
it more readable for *them*. Not everyone shares your views on readability.

<snip>

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

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

On Monday November 16 2015 13:51, in comp.lang.c, "asetofsymbols@gmail.com"
<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
> 
> 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

Perhaps an illustration would help.

What does the following function do, how would you invoke it, and what does it
return?

#define F for
#define R return
#define I if

int bs(int k, int *a, size_t n)
{
  int l,h;

  F(l=0, h=n-1; l<=h;)
  {
    int m;

    m = (l+h)/2;

    I(a[m]==k) R m;

    F(a[m]<k)
      l=m+1;
    else
      h=m-1;
  }
  R -1;
}



-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

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

On Monday, November 16, 2015 at 9:21:08 PM UTC, Lew Pitcher wrote:
> On Monday November 16 2015 13:51, in comp.lang.c, "asetofsymbols@gmail.com"
> <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
> > 
> > 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
> 
> Perhaps an illustration would help.
> 
> What does the following function do, how would you invoke it, and what does it
> return?
> 
> #define F for
> #define R return
> #define I if
> 
> int bs(int k, int *a, size_t n)
> {
>   int l,h;
> 
>   F(l=0, h=n-1; l<=h;)
>   {
>     int m;
> 
>     m = (l+h)/2;
> 
>     I(a[m]==k) R m;
> 
>     F(a[m]<k)
>       l=m+1;
>     else
>       h=m-1;
>   }
>   R -1;
> }
> 
> 
It's a binary search.
We're looking for the index of value k in the sorted array a;

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

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

On 16/11/15 21:20, Lew Pitcher wrote:
> On Monday November 16 2015 13:51, in comp.lang.c, "asetofsymbols@gmail.com"
> <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
>>
>> 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
>
> Perhaps an illustration would help.
>
> What does the following function do, how would you invoke it, and what does it
> return?
>
> #define F for
> #define R return
> #define I if
>
> int bs(int k, int *a, size_t n)
> {
>    int l,h;
>
>    F(l=0, h=n-1; l<=h;)
>    {
>      int m;
>
>      m = (l+h)/2;
>
>      I(a[m]==k) R m;
>
>      F(a[m]<k)
>        l=m+1;
>      else
>        h=m-1;
>    }
>    R -1;
> }


I w r t i o t s k (i f) o e m o.

(That is, the example is too simple to be an effective illustration.)

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

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

Lew Pitcher  wrote:

On Monday November 16 2015 13:51, in comp.lang.c, "asetof...@gmail.com" 

Perhaps an illustration would help. 

What does the following function do, how would you invoke it, and what does it 
return? 

#define F for 
#define R return 
#define I if 

int bs(int k, int *a, size_t n) 
{ 
  int l,h; 

  F(l=0, h=n-1; l<=h;) 
  { 
    int m; 

    m = (l+h)/2; 

    I(a[m]==k) R m; 

    F(a[m]<k) 
      l=m+1; 
    else 
      h=m-1; 
  } 
  R -1; 

}
____
This not compile because
for(a[m]<k) 
not compile

If that F is I than
l    m=(h+l)/2.     h
.    a[m]<k than increase 
.    l=m+1 h=h
It would be binary search of k
in the array a of size n
I would call 
r=bs(k, a, sizeof a);
Return r position in array a 
with a[r]==k
Or return -1 if not find that value.

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

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

If I have to say the true
I find difficult recognized
l from 1 from I
So I use 'l' only in label
'I' not remember I used it...

 other letters difficult
for me
to recognize are q and p and b
so I would use only one of them
in the same function

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

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

Programming language, or algorithm language is not
English not Italian nor German etc.
One can find some help
with these languages but it is different.
Like math language: It is different
from speak above language.

In both the last, has preeminence
redundancy symbols and indentation
good use of the page (or screen)
page, pedantic
Symbols use, logic math, location memory to fill with info .
Say things exactly in few words.

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

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

On 18/11/15 06:51, asetofsymbols@gmail.com wrote:
> Programming language, or algorithm language is not
> English not Italian nor German etc.

Right. So?

> One can find some help
> with these languages but it is different.
> Like math language: It is different
> from speak above language.

Different in some ways, similar in others.

> In both the last, has preeminence
> redundancy symbols and indentation
> good use of the page (or screen)
> page, pedantic
> Symbols use, logic math, location memory to fill with info .
> Say things exactly in few words.

That isn't a requirement, but clear communication *is* a requirement. To 
communicate your message clearly, use as many words as are necessary for 
the given audience. Your ludicrous #defines make no difference to the 
compiler, but they make a big difference to human readers of your code. 
Most people, faced with rubbish like #define R return, will not bother 
to read further.

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

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

On 16/11/15 18:33, Malcolm McLean wrote:

<snip>

> 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, that's not the reason. It's for brevity, pure and simple. And 
brevity at the expense of clarity is a poor trade.

<snip>

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

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

On 16/11/15 19:33, Malcolm McLean wrote:
> 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.
> 

Mathematical convention is to write much of information in natural
language, so that your single-letter identifiers are explained.  And
mathematical convention is that you usually have only a small number of
identifiers "in scope" at a time.

The equivalent in programming is using "i" as a loop variable, and other
short or single-letter identifiers in small local scopes where their
meaning is obvious.  And that is common practice - most people agree
that "for (int i = 0; i < 10; i++)" is fine, and clearer and more
readable than using "index" or "loop_counter" as the variable name.

But the bigger the scope of an identifier, the more expressive the
identifier needs to be.

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

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

David Brown <david.brown@hesbynett.no> wrote:

> Mathematical convention is to write much of information in natural
> language, so that your single-letter identifiers are explained.  And
> mathematical convention is that you usually have only a small number of
> identifiers "in scope" at a time.
> 
> The equivalent in programming is using "i" as a loop variable, and other
> short or single-letter identifiers in small local scopes where their
> meaning is obvious.  And that is common practice - most people agree
> that "for (int i = 0; i < 10; i++)" is fine, and clearer and more
> readable than using "index" or "loop_counter" as the variable name.
> 
> But the bigger the scope of an identifier, the more expressive the
> identifier needs to be.

Remember also that a mathematical proof of a hundred pages is still
considered to be large, and only rare proofs reach as many as a
thousand. Meanwhile, even I on my own have written programs whose
complete listings run to a hundred pages, and I don't work on large
projects, only medium ones. So programming needs even more expressive
names than mathematics, because there is just so much more of it to take
in at once.

Richard

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

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

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

> On Monday November 16 2015 02:00, in comp.lang.c, "asetofsymbols@gmail.com"
> 
> > 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).

Would you? I wouldn't expect them even there. The only place they ought
to be found is the IOCCC. Or a Perl program.

Richard

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

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

Richard Bos wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>
>> On Monday November 16 2015 02:00, in comp.lang.c, "asetofsymbols@gmail.com"
>>
>>> 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).
>
> Would you? I wouldn't expect them even there. The only place they ought
> to be found is the IOCCC. Or a Perl program.

I thought all Perl programs were potential IOCCC entries...

-- 
Ian Collins

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

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

On 11/17/2015 06:07 PM, Ian Collins wrote:
> Richard Bos wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>
>>> On Monday November 16 2015 02:00, in comp.lang.c, "asetofsymbols@gmail.com"
>>>
>>>> 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).
>>
>> Would you? I wouldn't expect them even there. The only place they ought
>> to be found is the IOCCC. Or a Perl program.
> 
> I thought all Perl programs were potential IOCCC entries...

I often wondered where this stereotype comes from. Most of the perl
scripts I've seen are no worse than typical C or C++ programs in this
regard. I'm sure it's possible to obfuscate perl code at least as badly
as you can obfuscate C code, but serious professionals don't do that,
and there's nothing about perl that forces or even encourages you to
write such code.
-- 
James Kuyper

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

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

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

csiph-web