Groups | Search | Server Info | Keyboard shortcuts | Login | Register


Groups > comp.compilers > #3301

Re: another C-like language? was Compilers :)

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.compilers
Subject Re: another C-like language? was Compilers :)
Date 2023-01-10 17:48 +0100
Organization A noiseless patient Spider
Message-ID <23-01-033@comp.compilers> (permalink)
References (1 earlier) <23-01-002@comp.compilers> <23-01-003@comp.compilers> <23-01-008@comp.compilers> <23-01-016@comp.compilers> <23-01-029@comp.compilers>

Show all headers | View raw


On 09/01/2023 18:41, Kaz Kylheku wrote:
> On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
>> don't want to go through them all, but I agree with you that the style
>> of "all your declarations at the start of the function" is long
>> outdated, and often - but not universally - considered a bad idea.)
>
> Declarations have never been required to be at the top of a function in
> C, because they can be in any compound statement block. I think
> that goes all the way back to the B language. [Nope, see the next message. -John]
>
> The "Variables at the top" meme may be something coming from Pascal.
> IIRC, in Pascal, compound statements aren't full blocks; they cannot
> have VAR declarations.

I suspect it is much older than that - in assembly programming, you do
not normally mix data and code sections.

> When programmers abandoned Pascal in the 1980s, they carried over this
> habit into C.
>
> I hate mixed declarations and code because it's almost as bad as
> variables-at-the-top. The scope of a declaration that is just planted
> into the middle of a compound statement block extends all the way to the
> end of the block. There should be a smaller enclosing block which
> exactly delimits the scope of that variable.  If some variable is used
> over seven lines of a 300 line function, those seven lines should
> ideally be enclosed in curly braces, so the variable is not known
> outside of those lines. Just planting an unwrapped declaration of the
> variable at the function scope level (outermost block) solves only half
> the problem. The scope of the variable starts close to where the
> variable is used, which is good; but it still goes to the end of the
> function, way past its actual semantic scope that ends at the last use.

If your variable is only used in 7 lines out of a 300 line function,
then perhaps your function is too long?

I agree that small scopes for variables are good, and put declarations
within compound statement blocks where practical (though I rarely make a
new block simply to hold a variable).  But that is not the sole purpose
of mixing code and declarations - it is not even the major purpose, IMHO.

The point is that you do not declare a variable until you actually have
something to put in it.  You never have this semi-alive object floating
around where it is accessible, but has no valid or known state.  You
never have an artificial initialisation, such as putting 0 in a variable
declared at the top of the function, in the mistaken believe that it
makes code somehow "safer".  You can make your variables "const" if they
do not change.  If you are using C++ (or other object-oriented
language), you avoid the inefficiency of default-constructing an object
and later assigning to it, instead of doing a single initialisation.

Of course this applies just as well to variables defined inside blocks
as to variables defined after code.

> A block like this can be repeated with copy and paste:
>
>   {
>     int yes = 1;
>     setsockopt(fd, SO_WHATEVER, &yes);
>   }
>
> This cannot: you will get redefinition errors:
>
>   int yes = 1;
>   setsockopt(fd, SO_WHATEVER, &yes);
>
> you have to think about ensuring that "int yes" occurs in one place
> that is before the first use, and the other places assign to it.
> Or invent different names.
>

This is something that I would prefer C and C++ to allow.  I think it
would improve the structure of some of my code, precisely as you describe.

I'd also like to be able to write :

	int x = 10;
	x += 20;
	const int x = x;	// Fix x - after this, x is constant

I wonder if anyone has made a proposal for adding this feature to C or C++ ?
[Variables at the top probably comes from Algol60 via Pascal.  For assembler,
depends on the assembler.  Lots of them let you have several sections in the
program and switch between the code and data sections as you go.  IBM mainframe
assemblers had this feature in the 1960s. -John]

Back to comp.compilers | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-02 12:28 +0200
  Re: Compilers :) Spiros Bousbouras <spibou@gmail.com> - 2023-01-02 20:52 +0000
    Re: another C-like language? was Compilers :) Steve Limb <stephenjohnlimb@gmail.com> - 2023-01-03 16:24 +0000
      Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-03 12:52 -0800
        Re: another C-like language? was Compilers :) arnold@skeeve.com (Aharon Robbins) - 2023-01-04 17:12 +0000
          Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-04 12:39 -0800
      Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-05 06:27 -0800
        Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-05 16:26 -0800
        Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-06 15:39 +0100
          Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 17:41 +0000
            Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-10 17:48 +0100
              Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-10 15:13 -0800
                Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-11 13:38 +0100
                Re: back in the 60s, another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-11 16:38 -0800
                Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:26 -0800
              Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-11 11:02 +0000
                Re: Scheme is not another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-12 02:54 -0500
              Re: another C-like language? was Compilers :) Bill Findlay <findlaybill@blueyonder.co.uk> - 2023-01-11 11:58 +0000
            Re: another C-like language? was Compilers :) Thomas Koenig <tkoenig@netcologne.de> - 2023-01-11 10:49 +0000
              Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:21 -0800
                Re: another C-like language? was Compilers :) Andy Walker <anw@cuboid.co.uk> - 2023-01-15 22:01 +0000
            Re: another C-like language? was Compilers :) "Luke A. Guest" <laguest@archeia.com> - 2023-01-13 18:25 +0000
              Re: another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-13 17:20 -0500
              Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-14 19:07 +0000
        Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-07 02:14 -0800
          Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-08 20:21 +0100
            Re: another C-like language? was Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-09 04:48 +0100
              Re: C scopes, another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-09 18:12 +0100
            Re: another C-like language? was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-09 11:24 -0800
    Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 13:41 +0200
  Re: Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-05 01:12 +0100
    Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 14:17 +0200
      Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 10:32 -0800
        Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 12:39 -0800
          Re: C and Java, was Compilers :) dave_thompson_2@comcast.net - 2023-01-28 10:37 -0500
            Re: C and archtecture, C and Java, was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 19:37 -0800
            Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-29 21:39 -0800

csiph-web