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

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

Is goto Still Considered Harmful?

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

Contents

  Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 11:02 -0500
    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 12:17 -0400
    Re: Is goto Still Considered Harmful? nospam@see.signature (Richard Maine) - 2014-03-12 09:20 -0700
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:30 -0500
        Re: Is goto Still Considered Harmful? Geoff <geoff@invalid.invalid> - 2014-03-18 17:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 07:34 -0400
            Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-19 12:08 +0000
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 10:07 -0400
                Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-19 17:05 +0100
              Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:27 -0500
        Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-19 20:35 +1100
          Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:26 -0500
    Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 16:47 +0000
      Re: Is goto Still Considered Harmful? Jos Bergervoet <jos.bergervoet@xs4all.nl> - 2014-03-12 19:07 +0100
        Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-12 23:36 +0000
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 00:23 +0000
            Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 01:18 +0000
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 02:08 +0000
                Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 02:21 +0000
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:17 +0100
          Re: Is goto Still Considered Harmful? Melzzzzz <mel@zzzzz.invalid> - 2014-03-13 01:53 +0100
        Re: Is goto Still Considered Harmful? Les Cargill <lcargill99@comcast.com> - 2014-03-13 01:46 -0500
      Re: Is goto Still Considered Harmful? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-13 10:56 +0100
      Re: Is goto Still Considered Harmful? "Nasser M. Abbasi" <nma@12000.org> - 2014-03-16 08:18 -0500
        Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-16 15:18 +0000
          Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-20 11:36 -0700
    Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-12 18:50 +0000
      Re: Is goto Still Considered Harmful? <william@wilbur.25thandClement.com> - 2014-03-12 12:49 -0700
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-12 21:54 +0000
        Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 16:57 -0500
        Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 15:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 19:02 -0400
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:58 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 20:09 -0400
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:44 -0700
        Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-12 23:40 -0500
          Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:25 +0100
          Re: Is goto Still Considered Harmful? Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-03-14 11:24 +0100
            Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-14 23:32 -0500
            Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 13:43 +0000
              Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-15 16:28 +0100
                Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 16:01 +0000
                  Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-17 08:51 +0100
      Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:22 +0100
    Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-03-12 15:34 -0500
    Re: Is goto Still Considered Harmful? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-03-12 17:48 -0700
    Re: Is goto Still Considered Harmful? jt@toerring.de (Jens Thoms Toerring) - 2014-03-13 01:06 +0000
      Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 03:59 -0400
        Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 05:02 -0400
          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-13 08:42 -0400
            Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-13 14:45 +0000
      Re: Is goto Still Considered Harmful? Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2014-03-13 07:42 -0600
        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-13 14:56 +0100
    Re: Is goto Still Considered Harmful? Wolfgang Kilian <kilian@invalid.com> - 2014-03-13 09:10 +0100
    Re: Is goto Still Considered Harmful? mark.bluemel@gmail.com - 2014-03-13 08:02 -0700
    Re: Is goto Still Considered Harmful? Thomas Koenig <tkoenig@netcologne.de> - 2014-03-13 21:09 +0000
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-13 21:24 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-13 22:36 +0000
          Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:02 -0500
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 04:07 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:56 -0500
            Re: Is goto Still Considered Harmful? helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) - 2014-03-14 09:17 +0000
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 22:42 +0000
        Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 17:13 -0600
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-13 16:46 -0700
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 01:17 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:04 -0500
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 10:41 +0100
                  Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 09:55 +0000
                    Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 13:16 +0100
                    Re: Is goto Still Considered Harmful? Seebs <usenet-nospam@seebs.net> - 2014-03-18 21:08 +0000
                      Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-18 17:41 -0400
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 00:45 +0000
            Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 21:40 -0600
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 01:02 -0400
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:36 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:30 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:51 -0400
                    Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-14 13:12 -0700
                  Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 06:46 -0700
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:29 +0000
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:47 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:43 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:52 -0400
              Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-16 17:15 -0500
                Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-16 16:04 -0700
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:11 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 06:00 +0000
    Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-14 08:32 +1100
      Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-14 23:10 -0400
    Re: Is goto Still Considered Harmful? Rosario193 <Rosario@invalid.invalid> - 2014-03-14 02:18 +0100
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:14 -0500
    Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 07:52 -0700
      Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-24 11:20 -0400
        Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 17:08 +0000
        Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-25 14:06 -0400
          Re: Is goto Still Considered Harmful? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-03-26 13:31 -0400
      Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-24 16:31 +0000
      Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 16:46 +0000
        Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 16:10 -0700
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-24 17:19 -0700
            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 02:56 -0700
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-25 07:34 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 10:57 -0400
                Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-25 16:09 +0000
                Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-25 16:14 +0000
                  Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-03-26 08:06 +1300
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 12:49 -0700
                  Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 14:05 -0500
                    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 15:20 -0400
                      Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-04 14:56 -0500
                        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-04 17:11 -0400
                          Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 12:03 +1300
                          Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-04-05 00:17 -0500
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 20:14 +1300
                          Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-09 14:30 -0500
                            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-09 16:37 -0400
                              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-09 14:01 -0700
                        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-04-05 15:21 +0100
                    Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 11:04 +1300
                      Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-04-01 02:45 +0300
                        Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 13:03 +1300
                          Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 12:01 +0300
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-05-22 21:22 +1200
                        Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 11:53 +0300
                Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 12:10 -0400
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 10:39 -0700
                    Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 13:42 -0500
                      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 15:16 -0700
                        Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 00:24 -0700
                          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-04-01 08:26 -0400
                            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 06:50 -0700
                              Re: Are setters Stil Considered Harmful? (was: Is goto Still Considered Harmful?) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-02 10:49 -0700
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:30 +0000
                Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-27 09:33 -0400
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:37 +0000
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 00:30 -0400
          Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-27 11:47 -0700
            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-27 20:39 -0400
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 01:40 +0000
            Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-28 10:09 +0100
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 09:48 +0000
              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-28 03:24 -0700
                Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-28 18:52 +0000
                Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-30 02:45 -0700
      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-24 12:53 -0700
      Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 15:02 -0700
        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-24 19:11 -0400
    Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 05:56 -0700

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

#42431

Ian Collins <ian-news@hotmail.com> writes:
> Stephen Sprunk wrote:
> > On 25-Mar-14 11:14, Kaz Kylheku wrote:
> >
> >> For instance, the function _dl_map_object_from_fd in the glibc
> >> dynamic linker:
> >>
> >> https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c
> >>
> >> goes from line 919 to 1623. (Commit 9455df...bef85a).
> >
> > A lot of that is whitespace, preprocessor directives or comments.  Also,
> > that function clearly does a sequence of operations that could have been
> > broken up into helper functions--even if it were the only caller.  My
> > bet is that it started out a lot smaller but grew over time as features
> > and special cases (or bug fixes) were added, a series of straws that
> > should have broken the camel's back long ago.
> 
> That function appears to be a classic case of the code rot that occurs
> when functionality as added without any thought to improving the
> design. One of the things I found surprisingly hard when managing
> development teams was getting programmers to refactor code before
> updating it.  It's all too easy just to pile on more functionality.
> This is usually a symptom of poor management not allowing time for
> code improvements and a lack of unit tests which support refactoring.

Oh, come on, that function is carp, there's no other word for it.

Phil
-- 
Religion is too important a matter to its devotees to be a subject of 
ridicule. If they indulge in absurdities, they are to be pitied rather
than ridiculed. -- Immanuel Kant (1724-1804), lecture at Konigsberg, 1775

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

#42433

Phil Carmody wrote:
>
> Oh, come on, that function is carp, there's no other word for it.

Ah Phil, you can which one of us has been corrupted by the politics of 
management!

-- 
Ian Collins

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

#44796

Ian Collins <ian-news@hotmail.com> writes:
> Phil Carmody wrote:
> > Oh, come on, that function is carp, there's no other word for it.
> 
> Ah Phil, you can which one of us has been corrupted by the politics of
> management!

Still a code monkey, and I like it that way. I've finally completed
the cycle of company sizes (peaking at Samsung last year, yikes),
and am now back at the beginning again, in a company with only 4
devs and a management hierarchy that only a mathematician would be 
prepared to actually call a "hierarchy".

Is that email address valid, I have a small favour to ask?

Phil
-- 
Religion is too important a matter to its devotees to be a subject of 
ridicule. If they indulge in absurdities, they are to be pitied rather
than ridiculed. -- Immanuel Kant (1724-1804), lecture at Konigsberg, 1775

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

#44798

Phil Carmody wrote:
>
> Is that email address valid, I have a small favour to ask?

Yes, I just checked it for the first time this year!

-- 
Ian Collins

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

#44794

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> >Oh, come on, that function is carp, there's no other word for it.
> 
>   A carp is a fish. The (other )word for it is »crap«.

Tell that to Uli:
 https://sourceware.org/bugzilla/show_bug.cgi?id=5070#c1 

Glibc, Uli, ... you don't see any connection?

Maybe quoting Uli is a Finnish Nokia thing. He's classic.

Phil
-- 
Religion is too important a matter to its devotees to be a subject of 
ridicule. If they indulge in absurdities, they are to be pitied rather
than ridiculed. -- Immanuel Kant (1724-1804), lecture at Konigsberg, 1775

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

#42405

On 03/25/2014 11:33 AM, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> Yes, but you've been asked to defend an assertion that there is a
>> C-specific preference for short functions.
> 
>   My assertion is that in C we (the majority of educated
>   programmers of today) prefer short functions. I do not wish
>   to make any assertion about whether this holds or does not
>   hold for any other language.

Well, in my experience, most C programmers seem to prefer function
lengths that I'm not willing to call "short". I can't say for sure how
many of them you would be willing to consider "educated", but I believe
that a significant fraction of them had CS degrees.

I do see a lot of short member functions written by educated C++
programmers, because they tend to make heavy use of classes with
inheritance, with each class in the inheritence tree having
responsibility for only a small piece of the total behavior of the code.
That responsibility can often be met by defining a small number of very
simple member functions. Non-member functions, however, (main() in
particular) are often very long.

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

#42408

On Monday, March 31, 2014 5:10:46 PM UTC+1, James Kuyper wrote:
> On 03/25/2014 11:33 AM, Stefan Ram wrote:
> 
> > James Kuyper <jameskuyper@verizon.net> writes:
> 
> I do see a lot of short member functions written by educated C++
> programmers, because they tend to make heavy use of classes with
> inheritance, with each class in the inheritence tree having
> responsibility for only a small piece of the total behavior of the code.
> That responsibility can often be met by defining a small number of very
> simple member functions. Non-member functions, however, (main() in
> particular) are often very long.
>
A lot of C++ programmers write short access functions, getField() and setField(), that simply
read and assign a member variable, maybe with a range check. Whilst you do need the odd one,
heavy use of getter and setters is usually a sign that the programmer hasn't really understood how
to abstract functionality. Whilst the idea is that the getters and setters can be over-ridden or
rewritten at a later date, that's unlikely to happen, more likely the code will need a total rewrite.

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

#42413

On 31-Mar-14 12:39, Malcolm McLean wrote:
> A lot of C++ programmers write short access functions, getField() and
> setField(), that simply read and assign a member variable, maybe with
> a range check. Whilst you do need the odd one, heavy use of getter
> and setters is usually a sign that the programmer hasn't really
> understood how to abstract functionality. Whilst the idea is that the
> getters and setters can be over-ridden or rewritten at a later date,
> that's unlikely to happen, more likely the code will need a total
> rewrite.

The usual rationale is that changing the member variable means you need
to update _other_ state in the object (or resource you're wrapping) as a
side effect; the setField() functions provide a place for that to
happen, and the getField() functions are for symmetry.  Or you may need
to get the current state from the wrapped resource, or calculate it, etc.

Some member variables _can_ be safely updated by callers, at least in
this version of the class.  But what if you may need to make them
private in a future version due to adding side effects?  Better to make
callers use the accessor functions now so they aren't broken by an API
change that _should_ be transparent to them.

(The above applies to OO interfaces in C as well, just minus the
syntactic sugar that C++ classes provide to make it a little less painful.)

Overloading operators (so callers appear to be directly updating a
member variable) seems more elegant in some respects, but it hides a
(possibly expensive) function call, which may introduce other problems.
 That's a general problem with C++'s operator overloading, not specific
to this.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#42423

On Monday, March 31, 2014 7:42:54 PM UTC+1, Stephen Sprunk wrote:
> On 31-Mar-14 12:39, Malcolm McLean wrote:
> 
> > A lot of C++ programmers write short access functions, getField() and
> > setField(), that simply read and assign a member variable, maybe with
> > a range check. Whilst you do need the odd one, heavy use of getter
> > and setters is usually a sign that the programmer hasn't really
> > understood how to abstract functionality. Whilst the idea is that the
> > getters and setters can be over-ridden or rewritten at a later date,
> > that's unlikely to happen, more likely the code will need a total
> > rewrite.
> 
> The usual rationale is that changing the member variable means you need
> to update _other_ state in the object (or resource you're wrapping) as a
> side effect; the setField() functions provide a place for that to
> happen, and the getField() functions are for symmetry.  Or you may need
> to get the current state from the wrapped resource, or calculate it, etc.
> 
> Some member variables _can_ be safely updated by callers, at least in
> this version of the class.  But what if you may need to make them
> private in a future version due to adding side effects?  Better to make
> callers use the accessor functions now so they aren't broken by an API
> change that _should_ be transparent to them.
> 
> (The above applies to OO interfaces in C as well, just minus the
> syntactic sugar that C++ classes provide to make it a little less painful.)
> 
That's the standard rationale. It does work sometimes. The reality is that
setting a member directly can't usually be replaced by an interface that
does something, because that would change the contract and break code in
unpredicatable ways.
E.g. we have a setSalary method that sets an employee's salary. We could 
decide that we'll update his tax bracket at the same time to keep the class
always consistent. But now we've broken logic that goes

employee.setSalary( newsalary);
if(employee.getTaxBracket() != taxBracketForSalary(newsalary))
{
  SendLetter("Your tax has changed");
  employee.updateTaxBracket();
}

So in fact we've got to rewrite the program. Which is possibly the best thing
to do.

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

#42441

On Monday, March 31, 2014 11:55:53 PM UTC+1, Stefan Ram wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> >E.g. we have a setSalary method that sets an employee's salary. We could 
> >decide that we'll update his tax bracket at the same time to keep the class
> >always consistent. But now we've broken logic that goes
> 
>   When the documentation of the public interface (the
>   contract) of the setSalary function already contained the
>   guarantee that this function will only change the salary and
>   nothing else, then changing this guarantee will change the
>   public interface of the entity, which in any case (not only
>   in the case of fields) means that all clients of the old
>   public interface are not necessarily valid clients of the
>   new interface. So, one usually tries to avoid to change
>   public interfaces, not only in the case of field and setters.
>
There's some truth in that.
The situation is that we have an employee, a salary, an associated tax band,
and when a change in salary results in a change in tax band, we need to 
send him a letter informing him of the fact.
So we've got three levels of task.
Lowest level - write the new salary to the field.
Medium level - ensure the tax band is calculated and represented correctly.
High level - send the letter.

The idea of abstracted get/setters is that a task at the lowest level can
be reimplemented as a task at a higher level. So instead of rewriting the
field, we recalculate the tax band or even send the letter.
But a change in the level of a function is much more likely to break things
deeply than a change in what the function does (e.g. a high-level
updateSalary() method sends a letter, we rewrite it to send a carbon copy 
to the printer as well. That change is of a different order to changing
setSalary() from a  field write to sending a letter). 

You do need some access functions. But they should be the exception.

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

#42448

On 4/1/14, 3:24 AM, Malcolm McLean wrote:
> On Monday, March 31, 2014 11:55:53 PM UTC+1, Stefan Ram wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> E.g. we have a setSalary method that sets an employee's salary. We could 
>>> decide that we'll update his tax bracket at the same time to keep the class
>>> always consistent. But now we've broken logic that goes
>>
>>   When the documentation of the public interface (the
>>   contract) of the setSalary function already contained the
>>   guarantee that this function will only change the salary and
>>   nothing else, then changing this guarantee will change the
>>   public interface of the entity, which in any case (not only
>>   in the case of fields) means that all clients of the old
>>   public interface are not necessarily valid clients of the
>>   new interface. So, one usually tries to avoid to change
>>   public interfaces, not only in the case of field and setters.
>>
> There's some truth in that.
> The situation is that we have an employee, a salary, an associated tax band,
> and when a change in salary results in a change in tax band, we need to 
> send him a letter informing him of the fact.
> So we've got three levels of task.
> Lowest level - write the new salary to the field.
> Medium level - ensure the tax band is calculated and represented correctly.
> High level - send the letter.
> 
> The idea of abstracted get/setters is that a task at the lowest level can
> be reimplemented as a task at a higher level. So instead of rewriting the
> field, we recalculate the tax band or even send the letter.
> But a change in the level of a function is much more likely to break things
> deeply than a change in what the function does (e.g. a high-level
> updateSalary() method sends a letter, we rewrite it to send a carbon copy 
> to the printer as well. That change is of a different order to changing
> setSalary() from a  field write to sending a letter). 
> 
> You do need some access functions. But they should be the exception.
> 

I suppose if your data model says that to meet data consistency rules
that are to kept, the lower two functions/operations are NOT part of the
"Public" interface of the class, but should be private or maybe
protected members. Your lowest level operation, being seemingly DEFINED
as just changing the member, should not be a member function in my mind.
The middle level, which sets the variable and updates other fields to be
consistent would be a function, but with access restrictions so that
only are in charge of maintaining the full constraints call it. This
also should be the only place where the member is changed (which is one
reason the lowest level shouldn't be a function, it will be, by
definition, a one liner called in all likelyhood one place.

The High level function is really the only place that you have your
public API. Things that don't know the details about the rules for
updating a salary should only deal with this.  And in fact, this
function should probably be the only place the medium level routine is
called. This could be a reason to say that the middle level shouldn't
even exist as a function, but there may be enough difference in
abstraction of these operations that it does make sense to have them
separate.

Note, that since the whole purpose of having a setter is so that it my
add any needed constraint update, anything that breaks when you add it
doing something (like writing the letter) was already broken, you just
couldn't see it, or should have already been documented as needing some
"special access" so that it was automatically reviewed (and perhaps
updated) when the change was made.

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

#42450

On Tuesday, April 1, 2014 1:26:10 PM UTC+1, Richard Damon wrote:
> On 4/1/14, 3:24 AM, Malcolm McLean wrote:
> 
> I suppose if your data model says that to meet data consistency rules
> that are to kept, the lower two functions/operations are NOT part of the
> "Public" interface of the class, but should be private or maybe
> protected members. Your lowest level operation, being seemingly DEFINED
> as just changing the member, should not be a member function in my mind.
> 
Effectively that's right. A setter is "kind of defined as just changing the member".
So it shouldn't be public, which means there's no reason for it to be a function.
>
> The middle level, which sets the variable and updates other fields to be
> consistent would be a function, but with access restrictions so that
> only are in charge of maintaining the full constraints call it. This
> also should be the only place where the member is changed (which is one
> reason the lowest level shouldn't be a function, it will be, by
> definition, a one liner called in all likelyhood one place.
> 
We've also got special cases. For example it's probably valid to copy an employee, so we'll need
to set the salary field there. Similarly in retrieving him from disk. Then when he retires or leaves
the company there might be a rule, or it might be added at a later date. 
> 
> 
> The High level function is really the only place that you have your
> public API. Things that don't know the details about the rules for
> updating a salary should only deal with this.  And in fact, this
> function should probably be the only place the medium level routine is
> called. This could be a reason to say that the middle level shouldn't
> even exist as a function, but there may be enough difference in
> abstraction of these operations that it does make sense to have them
> separate.
> 
There's fundamental difference. The middle level is only manipulating the employee. It needs to
know about the employee and the rules for tax bands (which probably means a connection to
some kind of tax law engine). But it doesn't need to know about letters and printers, nor should it.
>  
> Note, that since the whole purpose of having a setter is so that it my 
> add any needed constraint update, anything that breaks when you add it
> doing something (like writing the letter) was already broken, you just
> couldn't see it, or should have already been documented as needing some
> "special access" so that it was automatically reviewed (and perhaps
> updated) when the change was made.
>
The entire concept of "change the implementation but not the interface" is flawed, when you think
about it. With the exception of cosmetic changes to code, the only reason to change an implementation
is to change the object's behaviour in some respect. So what we really mean is "keep the interface valid".
That's not an easy thing to define. For example, say we move from drawing pixel lines to drawing
anti-aliased lines. That's fine if caller wants something to display to the end user, hopeless if he's 
doing post-processing of the output. That doesn't mean that the change is unreasonable, just
that we've got to be careful.
But getters and setters are probably more likely to break than other functions, if rewritten. They
create the illusion of object-oriented programming when in fact they're just syntactical sugar for
structures.

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

#42475 — Re: Are setters Stil Considered Harmful? (was: Is goto Still Considered Harmful?)

On Wednesday, April 2, 2014 12:59:36 PM UTC+1, Stefan Ram wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> >Effectively that's right. A setter is "kind of defined as just changing the member".
> 
>   There are different definitions of »setter«. For example,
>   some definitions say that a setter does not change a member,
>   but a property. Some definitions say that a setter does not
>   always change a member, but might conditionally not change a
>   member to protect class invariants, or might have additional
>   effects, such as »setVisible( false )« making a screen
>   object invisible. Some people seem to call every function
>   whose name begins with »set« followed by a word a setter.
>
There's a continuum between setting a field, range-checking and setting a field, setting and changing
another member, and triggering widespread changes.
However if you've got a matching pair of get/set functions, and a field which contains that value,
then I'd say you're using get/setters. I don't ban them totally - obviously a GUI checkbox, for example,
will reasonably have an internal state and a get/set pair to access it. But that's rather a special case,
it's a sort of graphical wrapper for a boolean which the user can edit, so you're giving the user direct
access to a field.
You might also have a background colour. But I'd be unhappy (though not too unhappy) about a
get / set background colour pair. In reality the user is probably going to want white or grey - if you
permit a "theme" then you don't really want it implemented by thousands of calls to set background
methods. And it's not clear what a set background should do if you move to a fancy 3d type effect
with a shadow under the tick. And if it's necessary to query the checkbox background as part of
caller's logic control, really his program is extremely badly designed.
So I'd prefer a "set appearance" method which offers a limited menu of aesthetically pleasing
colours.

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

#42171

Keith Thompson <kst-u@mib.org> wrote:

(snip, someone wrote)
>>   We here in comp.lang.c think that »functions should fit on
>>   one page« must not be followed slavishly as a rule, but it
>>   is a guideline.
 
> You appear to be quoting http://www.c-faq.com/; it would have been good
> to mention that.  It's hard to tell just what you're quoting.
 
> But there's nothing C-specific about the advice you cite; it just
> happens to be from a site that deals with C.  Would it not be equally
> applicable to any other language?

Maybe not. An APL program could be way too long at one page.
Some say unreadable no matter how short.

For assembler, programs naturally tend to be longer.

But yes, for a wide variety of languages the optimal length is
probably not too different from C.

-- glen

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

#42217

On 3/25/2014 3:30 PM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> But there's nothing C-specific about the advice you cite; it just
>> happens to be from a site that deals with C.  Would it not be equally
>> applicable to any other language?
>
> Maybe not. An APL program could be way too long at one page.
> Some say unreadable no matter how short.

Any APL program longer than 1 line is too long.  :-)

[...]

-- 
Kenneth Brody

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

#42173

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Keith Thompson <kst-u@mib.org> writes:
>>But there's nothing C-specific about the advice you cite; it just
>>happens to be from a site that deals with C.  Would it not be equally
>>applicable to any other language?
 
>  I take the context of the newsgroup I am writing in into
>  account.

(snip)

>  . In classical FORTRAN, IIRC Functions can be defined, but
>  they are not »functions« in the sense of C (not recursive).

C does require functions to be recursive, but most aren't.
The mathematical meaning of the word FUNCTION doesn't require
it to be recursive.

But Fortran did in 1990 add recursion, though it must be declared
as an attribute to such functions. 

There is an additional complication in Fortran, in that inside a
function the name of the function is normally a variable name, not
a function name. This can be changed in Fortran 90 and later to
allow for direct recursion.

-- glen

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

#42123

On 03/24/2014 07:32 PM, Stefan Ram wrote:
...
>   This is comp.lang.c; so, when someone asks about �goto�, we assume he
>   refers to �goto in C�. In C, we (except beginners) write short functions.

That has not been my experience. I tend to write short functions, but a
lot of the code I've seen written by other people involves very long
functions; thousands of lines in some cases. I don't think they were all
beginners (though I know that several of them were more familiar with
Fortran than with C).
-- 
James Kuyper

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

#42223

On Monday, March 24, 2014 6:32:40 PM UTC-5, Stefan Ram wrote:
> John Bode <jfbode1029@gmail.com> writes:
> >Is that example completely contrived?  I wish I could say it was.  It was 
> >inspired by real code I've had to review in the past (except that "foo" was
> >several *thousand* lines long and there were 12 or 13 more labels with
> >gotos branching all over the goddamned place).  
> 
>   As others and I have said before: One might as well claim that in this
>   case, the problem is not the use of gotos, but the huge size of functions.
> 

Large functions are not necessarily *hard* to debug, if you can be certain
of the control flow.  I'm arguing that adding gotos to the mix makes a bad
situation worse.  

The gotos were what made that particular code unfixable, not the size of 
it; the logic was impenetrable because the code branched all 
over the goddamned place with no apparent rhyme or reason.  Even when 
we did eventually figure it out, we could not fix anything without breaking
something elsewhere in the code; it was so tightly coupled with itself
that any change only degraded it.  
  
>   This is comp.lang.c; so, when someone asks about »goto«, we assume he
>   refers to »goto in C«. In C, we (except beginners) write short functions.
> 

Who's "we"?

I've written very large functions in the past, usually because I was
dealing with a brain-dead, simple-but-tedious-to-use interface where 
the code was on the order of

    huge_struct.a_member = a_value;
    huge_struct.another_member = another_value;
    huge_struct.yet_another_member = yet_another_value;
    ...
    huge_struct.omg_how_many_of_these_things_are_there = gaaaaahhhhh;
    do_something_with( huge_struct );

repeated multiple times with multiple huge_struct types; individual 
functions could top out at 500-800 SLOC, 80% of those being simple 
assignment statements because the API was *stupid*.
  
>   Of course, who here would deny that refactoring a huge old-style 
>   monolithic program into a modern procedural and structured program is 
>   a lot of (possibly unpleasant and difficult) work? But when one is doing
>   it for an appropriate pay, it might be fair.

For that particular program, we told the customer we could either rewrite
it from scratch or they could buy faster hardware to meet their performance
requirement.

They bought the faster hardware.

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

#42238

On 03/27/2014 06:24 PM, Stefan Ram wrote:
> John Bode <jfbode1029@gmail.com> writes:
>> Who's "we"?
> 
>   The collective of C programmers who write short functions in C.

That's close to being a tautology: of course people who write short
functions tend to believe that functions should be short. Your comment
would have been more meaningful if you could have, correctly, used "we"
to refer to a larger, or at least more authoritative, group of people.
-- 
James Kuyper

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

#42242

In article <lh2gci$65l$1@dont-email.me>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>On 03/27/2014 06:24 PM, Stefan Ram wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>>> Who's "we"?
>> 
>>   The collective of C programmers who write short functions in C.
>
>That's close to being a tautology: of course people who write short
>functions tend to believe that functions should be short. Your comment
>would have been more meaningful if you could have, correctly, used "we"
>to refer to a larger, or at least more authoritative, group of people.

Just can't admit that you f*cked up, can you?

(As I described in my earlier post...)

-- 
I've been watching cat videos on YouTube.  More content and closer to
the truth than anything on Fox.

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

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

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

csiph-web