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

David Brown <david.brown@hesbynett.no>
Tue, 10 Jan 2023 17:48:18 +0100

          From comp.compilers

Related articles
[8 earlier articles]
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-06)
Re: another C-like language? was Compilers :) marblypup@yahoo.co.uk (marb...@yahoo.co.uk) (2023-01-07)
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-08)
Re: another C-like language? was Compilers :) DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-01-09)
Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09)
Re: another C-like language? was Compilers :) Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-09)
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-10)
Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-10)
Re: another C-like language? was Compilers :) tkoenig@netcologne.de (Thomas Koenig) (2023-01-11)
Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-11)
Re: another C-like language? was Compilers :) findlaybill@blueyonder.co.uk (Bill Findlay) (2023-01-11)
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-11)
Re: back in the 60s, another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-11)
[7 later articles]
| List of all articles for this month |

From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.compilers
Date: Tue, 10 Jan 2023 17:48:18 +0100
Organization: A noiseless patient Spider
References: 23-01-001 23-01-002 23-01-003 23-01-008 23-01-016 23-01-029
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="82433"; mail-complaints-to="abuse@iecc.com"
Keywords: design
Posted-Date: 10 Jan 2023 17:16:27 EST
Content-Language: en-GB
In-Reply-To: 23-01-029

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]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.